1. Field
This disclosure relates generally to computers, and, more particularly, to client-server architecture infrastructure.
2. Background
Most businesses use multiple networked servers, in some cases, many, many servers networked into clusters to handle their IT infrastructure needs. However, typical server deployments, particularly data center servers, underutilize server capacity for various reasons, for example, to allow for performance spikes or due to the possibility of interference between applications/programs. Note, as used herein, the terms “application” and “program” are used interchangeably to refer to non-operating system software that can be deployed and run on a server.
In general, if there is a need to add new applications/programs that require network discoverability into that network, currently either new additional servers or significant changes are required, which can be a costly endeavor in terms of added equipment (i.e., hardware and associated physical items), the extent of the network changes that may be needed, and the associated cost of the maintenance/personnel and potentially, the cost of downtime.
It is well known that applications/programs rarely use the full capabilities of existing servers on which they run, particularly in a clustering environment, leaving many servers with underutilized, excess capacity. Because of the way programs are written in order to be able to communicate with the “outside world” (i.e., other computers on the network, be it a small network within the company or the internet), if one needs to add an application/program in a clustering environment it is extremely difficult to use that underutilized, excess server capacity alongside the existing (i.e., “legacy”) applications/programs. Certain classes of applications use a technique called application discovery to advertise their presence on a network. When such an application is added to a network, it needs to be configured with one or more ports through which other programs will communicate with it. To do this, when the application is initially installed or run on a server, the application will “announce” to the network “I am here” and provide a zero value for the port value indicating where “here” is. The operating system, which maintains a table of all used and available ports for each server (denoted by a “Host Name”), will then assign a free port in place of the zero value, and thereafter, that is the port through which the application/program will be reachable from the other programs. Various programs may be used to implement the service discovery process/protocol including, for example, in the Linux™ environment, Apache™ ZooKeeper™, Consul™, Etcd™, Eureka™, etc.
Unfortunately, a current trend is to use “lightweight containers” for applications in clustered server environments. This creates a technological impediment that prevents, or makes very difficult, the use of any existing excess server capacity for applications of this class. That is because each lightweight container must be isolated from any other lightweight containers (hereafter referred to as “legacy components”) on the same server(s), i.e., they cannot use any of the same ports. Yet, each lightweight container has its ports independently dynamically assigned without regard to any other lightweight container. As a result, presently, the only way to ensure independence when adding a new lightweight container to an existing server would be to add a new hostname for that lightweight container on that existing Host (if possible). However, adding a new hostname requires significant additional detailed work, additional IP addresses, it requires new security for that Host, and additional complexity that must be supported, etc.
Thus, there is presently a significant technological problem inhibiting the ability to make use of that excess capacity by adding applications that run in lightweight containers onto one or more servers that already contain legacy components.